(此圖由 AI 生成)

今天來看常被搞混的敏捷、迭代與增量。

迭代式開發

重複進行多次迭代：每次迭代都進行需求分析、設計、實施和測試，逐步改進產品。

交付

不一定每次都交付完整可用的產品，但會有一個可評估的版本或功能原型。重點在逐步完善和改進產品，每次迭代後不一定能交付可用的產品，但每次都會更接近可用。

例子

以腳踏車的組裝，初始階段交付的是輪子，隨著進展，逐步交付加裝車架、鏈條、齒輪、坐墊等版本，最終到所有零件裝到一起，最終才形成一個可用的完整腳踏車。

增量式開發

交付

分階段交付。每次交付一部分完整可用的產品，逐步增加功能和改進。重點在每次增量交付的部分都是完整且可用的功能。

例子

以交通工具的升級為例，初始交付的是腳踏車，之後逐步增量交付變成電動腳踏車、125cc機車、最終交付一台哈雷機車。每個階段交付的產品都是可以獨立使用的。

敏捷開發

• 結合迭代和增量：每次迭代都交付可用的產品增量，並基於回饋進行持續改進
• 靈活和適應性強：強調快速響應變化，允許在開發過程中靈活調整需求和計劃。
• 持續回饋和改進：每次迭代結束後進行反思和改進，通過持續的客戶回饋來調整和改進產品。

例子

在軟體開發中，以兩週為一個週期來開發一個全新的APP，

在第一版 v1 的 MVP 最小可行性產品問世前，每次交付功能都增加一點，並且團隊隨著商業市場和需求方不斷調整功能。從 v0.1 → v0.2 → v0.3 → v0.xx → v1。

例如，v0.1 可能只有 UI、v0.2 可能只有某幾個頁面、v0.3 因為後端 API 好了加入商業邏輯…etc，之前的 0.xx 版不一定可以使用，但到了 v1 前後端都接上，是一個可用的最小可行性的 APP 產品了。

接著，上市後繼續更新產品，從 v1 → v2 → v3 不斷更新與追加功能，每次改版都是能用的版本。在 v1 之前的交付偏向迭代，在 v1 之後的交付偏向增量。

表格比較差異

再一次我會怎麼建議？

標題的「再一次我會怎麼建議」源自于我對公司某次 retro 會議的反應，該 retro 會議也是刺激我學習 PMP 的原因之一，先感謝部門同事們都是偏向價值取向，而不是形式主義，所以我才能反覆思考，再一次我會怎麼建議。(求生慾旺盛)

不少混合制公司標榜敏捷，但其實是小(功能)專案走敏捷、大(功能)專案變瀑布流，這很微妙，進入開發前花了公司 4/5 的時間在那邊討論，只留給開發團隊 1/5 時間，好像很合理，可你要說最後開發團隊 1/5 時間的規格很完整嗎？啊也沒有，規格也會變動。

也就是變成走瀑布式的事前需求斡旋與釐清 → 設計 → 開發 → 測試 → 上線，可是 Deadline 又被部門主管或 PM Lead 先喊死，導致只要開發團隊一說啊因為怎麼了所以開發時間要增加，會導致測試時間被壓縮，QA 就要在剩的時間極限測試。

我們寫 JavaScript 和 TypeScript 並不代表我們人也真的是單執行序要同步一行一行執行。如果新功能開發周期能提早進入開發階段，我們可以用敏捷 (或者說..著重在其中的「迭代式開發」)，RD 可以隱藏新產品功能的路口，只要 Web 或 APP 不廣撒對外的正式路口，可以包在當前版本先上到 Prod 正式環境，例如 UI 刻好也 UI Review 沒問題，那直接 release 發佈到正式環境。

對，上線一個不能用的功能服務，但是前端只要路口隱藏好根本不用擔心一般使用者會碰到。若時光倒流再讓我回到當時，我會這麼建議：先側重迭代式開發，頻繁交付，先上一個不能用的功能也沒關係，後續不斷迭代至可用。

這邊強調：先上一版使用者不能用的功能，不代表是團隊無法驗證的內容。前面也說了，UI 刻好並且設計師 UI Review 沒問題才 release，也就是每次 Sprint 仍然都有驗證交付物的流程。

害怕部分內容重工的心態，應證了心裡仍是瀑布式開發

但是以筆者經驗，談到這種方案，公司內就會有人反對，理由是：

「這樣 QA 測試或設計師檢查 UI 時，難免會重工，這個 Sprint 和下個 Sprint 可能還是會測到相似的東西。」

哇，這話題一聽就知道精彩了。因為這樣的擔憂，其實正好透露出說這話的人骨子裡，仍然深受瀑布式心態影響。為什麼會害怕重工？除了程式碼整合的問題，更根本的，其實就是預設了「需求會變動」，那所以之前測過的東西，未來也可能要重測對吧？

敏捷的重點是擁抱變化，而不是逃避變化。會擔心重工，其實反映出 Sprint 的切分方式出了問題：可能是需求沒被有效拆解，又或是 PM 與 RD Lead 在面對大專案時，缺乏能力把工作拆成可以漸進交付的小顆粒項目，導致每次 Sprint 無法產出可驗收的交付物。待過「台灣式敏捷」的朋友應該懂這個痛，就是小專案敏捷、大專案瀑布，流程名稱看起來是敏捷，實際上卻在照瀑布走。

說到底，這些對重工的擔憂，本質上是一種對穩定的渴望。但問題是，若一邊口頭說「我們是敏捷團隊」，一邊卻在變動發生時情緒激動、態度抗拒，那其實就陷入一種偽敏捷的矛盾裡。既然變動是常態，那就應該用設計流程去應對它，而不是害怕它。

那些本來就要一直測的，不如交給自動化測試

另外，害怕重工還有一個常見原因：公司還在靠人力手測，缺乏自動化測試機制。

如果每次改版、每次疊加新功能都得靠 QA 用手點一次，那當然會累，當然會怕內容反覆改到崩潰。但如果這些本來就需要頻繁驗證的邏輯，能透過單元測試、自動化整合測試或 UI 測試來處理，那這類「重複驗證」就不會是人的痛苦了，而是測試流程本來就該承擔的範疇。

說穿了，不是重工不能接受，而是手工重工太痛苦。 這時候與其討論怎麼減少重測次數，不如投資在測試自動化的建置上，讓 QA 真正能專注在變動幅度大的地方，而不是每次功能更新都得「人工再來一次」。

結語

希望今天的內容能幫助大家了解這三者差異，最後有一點要說，我在寫全真題時遇過，題目若出現迭代兩個中文字，答案不一定就是迭代式，千萬要小心陷阱。

敏捷或迭代式開發的核心價值之一就是允許學習後調整方向，如果一開始就不願意多花一次 UI Review 或 QA 測試的工夫，那其實根本不適合走這類方式。與其假裝世界是穩定的、不如接受它的混亂，並建立一個能應對變動的工作流程。

比起一次到位的完美交付，更務實的策略是：先交付一版「驗證過但尚未完備」的結果，讓整個團隊有東西可以討論、有方向可以前進、有原型可以調整，而不是一直在腦中想像出完美規格、結果一做下去就被現實打臉。